home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 11238 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Please Read!!
  5. Date: 22 Mar 1996 11:08:16 -0800
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4iutr0INNsgb@keats.ugrad.cs.ubc.ca>
  8. References: <4il2kq$18i1@ns2.ryerson.ca> <danpop.827237966@rscernix>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <danpop.827237966@rscernix>, Dan Pop <danpop@mail.cern.ch> wrote:
  12.  >In <4il2kq$18i1@ns2.ryerson.ca> asaporta@jupiter.scs.Ryerson.CA (Avram Saporta) writes:
  13.  >
  14.  >>  I am doing a paper called;
  15.  >>     'By making C++ compatible with C, Stroustrup has "created a monster"
  16.  >>which is neither good Object Oriented Language nor a suitable replacement 
  17.  >>for C.'
  18.  >
  19.  >I tend to agree with this statement.  OTOH, the feature that is 
  20.  >"responsible" for C++'s success over all the other OOPL available is
  21.  >the "compatibility" with C.
  22.  
  23. It could also be that it generates fast machine code compared to other OOPL's,
  24. some of which require elements of interpretation at run-time.
  25.  
  26. I have been ignoring C++ for the longest time, but I have recently taken it
  27. upon myself to read through the ARM by Stroustrup and Ellis.
  28.  
  29. Many of the features of C++ are neat, but they are mostly cosmetic. I also
  30. believe that if they are carelessly used, they lead to code that just does
  31. insanely many function calls.
  32.  
  33. It's neat, for instance, that objects encapsulate functions, and that an
  34. object's constructor and destructor is automatically called. But to me, this is
  35. just a syntactic/semantic nicety that offers no real advantage over using a
  36. structured approach.  It hides a lot of information: what looks like a harmless
  37. ``new'' declaration could unwittingly cause the execution of code that has
  38. all kinds of side-effects. And even the C++ FAQ admits that operator
  39. overloading is mere ``syntactic sugar''.
  40.  
  41. I recently read an article in a magazine published by the ACM dedicated to OO
  42. programming. (I will dig up the precise reference on request).
  43.  
  44. A study was made of a team of experienced C programmers who had little or no
  45. knowledge of C++. They had to study the language for some time and were then
  46. given implementation tasks. I think that the given task was to write a program
  47. that cross-references words in a text file.
  48.  
  49. The study found that OO design and implementation is difficult, rather than
  50. easy as the hype would lead you to believe, and doesn't necessarily yield a
  51. program that is simpler, and easier to understand or maintain.
  52.  
  53. Only one programmer was familiar with the standard C++ object classes and he
  54. reused their functionality. But it turned out that his solution was actually
  55. more complex and took just as long to deliver as the solutions of other
  56. programmers who wrote code from scratch. An argument is made in the article
  57. that truly re-usable components are not easy to develop.   From the point of
  58. view of a programmer who doesn't even know whether it's worthwhile to make a
  59. particular component general enough to be used in some unrelated project (that
  60. is, whether it will actually BE reused), writing reusable code is just an extra
  61. hassle.
  62.  
  63. I'm going to dig up this article again, because it's very interesting. It is
  64. also published in a magazine dedicated to object-oriented design and
  65. programming, so I take to be a credible admission of the weaknesses of the
  66. paradigm from some of its very proponents.
  67. -- 
  68.  
  69.